🦋 Changeset detected

Latest commit: c32c1be

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

Could this combine with this transform?
#2772
Maybe this covers wrap mode???
@santino @ntziolis

This is an interesting transform, but it can only deal with field hoisting, whilst my replace-field transform is primarily designed to override schema bits and so hoisting there is mostly a side conveniency feature.

I would personally avoid having two plugins that can achieve the same goal even if in different ways.

I think wrap mode can be implemented in replace-field transform, it just needs custom work across transformSchema and most importantly transformRequest and transformResponse.

I could start looking into that if we agree to go towards this path.

BTW I like here the idea of renaming the field, I will most likely add that to replace-field, it feels very relevant.
As for filtering args, it is convenient here, but in replace-field you can achieve it by defining a new GraphQL type with the args you want; this would override the base field you define as a source.

@ntziolis maybe you can have a look at what I did with replace-field and see if something like that would work for you.

@santino Replace field seems significantly more powerful with the ability to hoist fields as well. Hence there is no need for a standalone hoist field transform anymore. Let me know if I can assist in creating a wrap mode version of your transform.

Glad to hear that can work for you.

Do you need wrap mode in order to start using the plugin?
I haven't started working on it yet.

If there is a need for that, as a feature request, then I will start looking into it ASAP; otherwise, I will leave it for when I have more spare time.

But keen to solve your use case, since you even created a PR for that.

@santino We have been successfully using your transform. Here are some comments:

• the transform is very powerful and enables A LOT of things and we are already heavily making use of it
• it took us quite some time to understand how configuration done.
  • I think the documentation would benefit from a set of simple concrete use cases that don't build on each other
  • Which is not to say to not have one full blown example that pulls everything together as well
  • I'd be open to create a PR that builds on the existing documentation to assist others moving forward
• it feels like from / to are backwards. Any chance this could be reversed? This actually cost us the majority of time.
• one very powerful feature is the inline type + composer that can be used for intermediary purposes
  • it would be worth pointing out this use case more explicitly (that the type is not actually used in the end)
  • apart from that it would be great to specify type defs as part of a replacement in addition to globally all replacements
    • the list of replacements can get quite large
    • this way the
  • that said I also see use cases where a type def should span all replacements
• it should be possible to replace to fields that do not exist yet right now one has to go the route via an intermediary type
• retaining args when hoisting is often key use case when hoisting
  • any list call that supports pagination
  • but returns some funky / ugly return type that one just wants to clean up
  • without retaining the args that appear along the path this transform cant be used for this purpose

@ntziolis, your feedback is very relevant and I thank you for that!

I have some comments but I am thinking that is probably best to close this issue, so you can open a new one focused on the replace-field transform.
Most likely your comment above is a perfect conversation starter for the new issue.

Let's keep going on a dedicated thread :)

Closing as discussed

Reopening as discussed in #2975. Together with #3185 this transform is meant to replace the replace-fields transform.

Continuing discussion from here:

In this regard please note that I plan to extend the hoist transform to support glob patterns in the path Added hoist field transform package + docs #2862
this is to enable use cases e.g. where all list calls, return responses where the actual results are wrapped in some intermediary type
assuming the structure of these intermediary results is the same + its possible to create a glob pattern that matches all list calls it would then be possible to hoist the actual results and remove the intermediary type for all list calls at once

@santino For our use cases the support for glob pattern in the hoist field path would be immensely helpful. As of now the wrap transform leverages the HostFieldTransform from the graphql-tools which does not support patterns.
If we want to support glob patterns in the path. Should this be done in the mesh transform or in the downstream package? Since we would need the same targeting logic also for bare it might make sense todo this in the mesh transform, but I'm not certain how big the overlap would really be.

@santino The existing HoistField transform from the graphql-tools package, which is used for the wrap transform does not currently support lists in the path. I have created a bug report for this here.

When creating the bare version of hoist field we should ensure that lists in path are properly supported right from the start.

This pull request is being automatically deployed with Vercel (learn more).
To see the status of your deployment, click below or on the icon next to each commit.

🔍 Inspect: https://vercel.com/theguild/graphql-mesh/6UoiEAeJ1fy6tJQVaM9pJrPeLcGy
✅ Preview: https://graphql-mesh-git-fork-ntziolis-hoist-field-transform-theguild.vercel.app